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REMARKS 

The Non-Final Office Action mailed November 13, 2008 considered claims 1-12 and 14- 
28. Claim 12 was objected to because of an informality. Claims 1, 7, 10-12, 14, 17-21 and 25- 
28 were rejected under 35 U.S.C. 103(a) as being unpatentable over Phaal (US 6,006,269) 
hereinafter Phaal, in view of Chang et al. (US 6,035,324) hereinafter Chang, and further in view 
of Bucur et al. "The Influence of the Structure and Sizes of Jobs on the Performance of Co- 
Allocation" hereinafter Bucur. Claims 14, 17-21 and 25-28 were rejected under the same 
rationale as claims 1, 7, and 10-12, since they recite substantially identical subject matter. 
Claims 2-5, 8, 9, 15, 16, 23 and 24 were rejected under 35 U.S.C. 103(a) as being unpatentable 
over Phaal in view of Chang, further in view of Bucur, further in view of Mukundan et al. (US 
2007/0016639) hereinafter Mukundan. Claims 15, 16, 23 and 24 were rejected under the same 
rationale as claims 2-5, 8, and 9, since they recite substantially identical subject matter. Claim 6 
was rejected under 35 U.S.C. 103(a) as being unpatentable over Phaal in view of Chang further 
in view of Bucur further in view of Official Notice. Claim 22 was rejected under 35 U.S.C. 
103(a) as being unpatentable over Phaal in view of Chang further in view of Bucur, further in 
view of Garg et al. (US 2002/0138613) hereinafter Garg} 

By this amendment claims 1, 4, 5, 10, 14, and 23-28 are amended. 2 Accordingly, claims 
1-12 and 14-28 are pending, of which claims 1, 14, 26, and 27 are the independent claims at 
issue. 

The invention is generally directed to regulating client requests in an electronic 
messaging environment. For example, claim 14 recites a method for regulating client requests so 
as to provide an improved user experience when the messaging server is experiencing increased 
load. Claim 14 defines a computer system receiving a client data request from a client. The 
client data request requests that message related data for a user of the client be returned to the 
client. The computer system determines that it is unable to process the client data request based 
on the current load of computer system. The current load is indicative of resource consumption 



1 Although the prior art status of the cited art is not being challenged at this time, Applicant reserves the right to 
challenge the prior art status of the cited art at any appropriate time, should it arise. Accordingly, any arguments and 
amendments made herein should not be construed as acquiescing to any prior art status of the cited art. 

2 Support for the amendments to the claims are found throughout the specification and previously presented claims, 
including but not limited to paragraphs [0027]-[0029],[0037]-[0039],[0042], [0046], [0053]-[0055],and Figures 1 
and 4. 
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at the computer system as a result of the computer system sending message related data to other 
clients from among the plurality of different clients. The determination is made subsequent to 
receiving the client data request. 

The computer system adaptively generates a wait hint for return to the client. The 
adaptively generated wait hint includes an indicated wait time. The wait time indicates an 
amount of time to the client that the client is to wait before resending the client data request to 
thereby reduce the load at the computer system, the adaptively generated wait hint generated by a 
wait hint generation algorithm. The wait hint generation algorithm is configured to adaptively 
generate a wait hint each time the client data request is received at the messaging server but not 
processed based on the messaging server tracking how many times the client data request was 
previously received but not processed. Wait hints are generated up to a specified number of times 
the messaging server detects that the data request is received at the messaging server but not 
processed at the messaging server. After the specified number of times, the messaging server 
processes the client data request to return the message related data in response to the client data 
request. Accordingly, the message server controls when delayed client data requests are 
eventually processed even when the messaging server is busy. 

The computer system sends a buffer to the client. The buffer is responsive to the client 
data request. The buffer has a plurality of data fields including an error code field and a response 
data field. The error code field contains a server busy error code and the response data field 
contains the adaptively generated wait hint. The server busy error code indicates that the 
messaging server did not process the client data request. The adaptively generated wait hint 
indicates to the client to wait the indicated wait time before resending the client data. 

Claim 27 is a computer program product claim similar to method claim 14. Claim 1 is a 
claim similar to claim 14 from a client perspective. Claim 26 is computer program claim similar 
to method claim 1 . 

Applicants respectfully submit that the cited art of record does not anticipate or otherwise 
render the amended claims unpatentable for at least the reason that the cited art does not disclose, 
suggest, or enable each and every element of these claims. 

Phaal describes an admission control system with message admitted or deferred for re- 
submission at a later time on a priority basis. Applicants' submissions with respect to Phaal are 
addressed in detail in response to a prior office action. As noted in the Office Action, Phaal fails 
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to specifically disclose (A) that the wait hints are generated based on the number of times a 
message has been deferred or B) that the message may only be deferred a specified number of 
times. (Office Action, page 4) 

Chang is cited to cure the failure of Phaal to disclose (A). Chang describes an 
exponential back off procedure to control delay between connection attempts, having increased 
delay as the number of attempts increase. (Col. 9, 11. 54-55). 

Bucur is cited to cure the failure of Phaal to disclose (B). Bucur describes that under a Fit 
Processor First Served scheduling algorithm counters can be used as an aging mechanism. Each 
job counts the number of times it was jumped over by jobs that were behind it in a queue, but 
were scheduled before it. When the counter reaches a chosen limit, the schedule is not allowed 
to overpass the job anymore. (Section 2.3). Bucur may be sufficient for determining overpasses 
in a queued environment, where jobs are aware of each other. However, Bucur fails to address 
any non-queued environments, where a job does not necessarily know the existence of other jobs 
or that other jobs are being serviced out of order. In these environments, a job counting its own 
number of overpasses would have limited meaning, if it could even be achieved, since the job 
has no way to identify other competing jobs. 

Mukundan describes managing status of requests in a client server environment. 
Mukundan describes a notification mechanism using RPC. (Paras. [0154] and [0155]). A 
variety of notification messages, including NotifyLongOpProgress, can be sent to a client to 
notify a client of data updates and changes, (paras. [0157]-[0185]). The NotifyLongOpProgress 
notification indicates a long action is in progress, (para. [0184]). When a server determines that 
a request is to take a long time, the server can notify the client, (para. [0532]). 

The Office Action submits that it is obvious that a reply includes a buffer with an error 
code to let the client know it is busy because it updates a progress bar. (Office Action, page 8). 
However, the server in Mukundan does not reject processing of a connection request and instruct 
the client to attempt to reconnect at a later time. All connections are processed to completion 
with no further action from the client (although some may take a long time). Thus, although the 
server may encounter an error during subsequent processing for a received request (see paras. 
[0191], [0192], [0195], [0198]-[0215], [0245]), there is no consideration of an error associated 
with rejection of a client request. Without such an error, there is no motivation to instruct a 
client with respect to when a retry may be appropriate. 
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A notification, such as, for example, a NotifyLongOpProgress, provides the client with 
additional information related to the server processing (e.g., that it will take a long time). The 
client can use such information, for example, to avoid a client side time out (paras. [0528]- 
[0530]). 

Accordingly, the cited art fails to teach or suggest, either singly or in combination: 
an act of adaptively generating a wait hint for return to the client, the 
adaptively generated wait hint including an indicated wait time, the wait time 
indicating an amount of time to the client that the client is to wait before 
resending the client data request to thereby reduce the load at the computer 
system, the adaptively generated wait hint generated by a wait hint generation 
algorithm, the wait hint generation algorithm configured to: 

adaptively generate a wait hint each time the client data request is 
received at the messaging server but not processed based on the messaging 
server tracking how many times the client data request was previously 
received but not processed, up to a specified number of times the 
messaging server detects that the data request is received at the message 
but not processed at the messaging server, after which the messaging 
server processes the client data request to return the message related data 
in response to the client data request such that the message server controls 
when delayed client data requests are eventually processed even when the 
messaging server is busy; and 

an act of sending a buffer to the client, the buffer responsive to the client 
data request, the buffer having a plurality of data fields including an error code 
field and a response data field, the error code field containing a server busy error 
code, the server busy error code indicating that the messaging server did not 
process the client data request, the response data field containing the adaptively 
generated wait hint, the adaptively generated wait hint indicating to the client to 
wait the indicated wait time before resending the client data, 
as recited in claim 14, when viewed in combination with the other limitations of claim 14. For at 
least this reason, claim 14 patentably defines over the art of record. Claim 1 also patentably 
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defines over the art of record for similar reasons. Claims 2-12 and 15-25 also patentably define 
over the art of record at least for the same reason as their corresponding base claim. 

However, many of the dependent claims also independently distinguish over the art of 
record. For example, the cited art fails to teach "a buffer that contains the wait hint in a variable 
length operation specific response data portion of the buffer" as recited in claims 5 and 24. 
Further the cited are fails to teach refereeing to "the differing wait time read from a wait interval 
configuration file", as recited in claim 28. 

At least for the same reasons as claims 14, 24, and 28, claim 27 also patentably defines 
over the art of record. For example, the cited art fails to teach or suggest either singly or in 
combination: 

referring to external configuration data to adaptively generate a 
wait hint each time the client data request is received at the messaging 
server but not processed at the messaging server based on the messaging 
server tracking how many times the client data request was previously 
received but not processed, up to a specified number of times the 
messaging server detects that the client data request is received at the 
messaging server but not processed at the messaging server, after which 
the messaging server processes the client data request to return the 
message related data in response to the client data request such that the 
message server controls when delayed client data requests are eventually 
processed even when the messaging server is busy, the specified number 
of times being stored in the external configuration data; and 
sending data responsive to the data request in a Remote Procedure Call 
(RPC) response buffer to the client, the RPC response buffer having a plurality of 
data fields, including an error code field and a response data field, the error code 
field containing a server busy error code and the response data field containing 
the adaptively generated wait hint, the server busy error code indicating that the 
messaging server did not process the client data request, the response data field 
included in a variable length operation specific response data portion of the RPC 
response buffer, the adaptively generated wait hint indicating to the client to wait 
the indicated wait time before resending the client data request. 
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as recited in claim 27, when viewed in combination with the other limitations of claim 27. For 
similar reasons, claim 26 also patentably defines over the art of record. 

In view of the foregoing, Applicant respectfully submits that the other rejections to the 
claims are now moot and do not, therefore, need to be addressed individually at this time. It will 
be appreciated, however, that this should not be construed as Applicant acquiescing to any of the 
purported teachings or assertions made in the last action regarding the cited art or the pending 
application, including any official notice. Instead, Applicant reserves the right to challenge any 
of the purported teachings or assertions made in the last action at any appropriate time in the 
future, should the need arise. Furthermore, to the extent that the Examiner has relied on any 
Official Notice, explicitly or implicitly, Applicant specifically requests that the Examiner 
provide references supporting the teachings officially noticed, as well as the required motivation 
or suggestion to combine the relied upon notice with the other art of record. 

In the event that the Examiner finds remaining impediment to a prompt allowance of this 
application that may be clarified through a telephone interview, the Examiner is requested to 
contact the undersigned attorney at 801-533-9800. 

Dated this 13 th day of February, 2009. 




RICK D. NYDEGGER 
Registration No. 28,651 
MICHAEL B. DODD 
Registration No. 46,437 
Attorneys for Applicant 
Customer No. 47973 
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